METHOD FOR BROWSING VARIOUS INTELLIGENT 
DESIGN DATA ABSTRACTIONS 



The instant application claims the benefit of U.S. Provisional Application Sen No. 
60/213,349 filed on June 22, 2000. 

Field of the Invention 

The present invention is in the field of software. Specifically, the present 
invention is in the field of computer aided design and electronic design automation 
software used for the design and construction of printed circuit boards and similar 
electronic devices. 



Background Of The Invention 

Modern technology companies are completely dependent on the Computer Aided 
Design/Electronic Design Automation ("CAD/EDA") tools for designing products. In 
the design process, CAD/EDA systems are used to capture all of the relevant engineering 
information from the high level conceptual design all the way to the smallest physical 
detail such as components, screws and buttons. Figure 1 shows an overview of a printed 
circuit board product cycle life. 

During the design process various engineering, design, marketing, quality and 
manufacturing sectors of the organization need a means of access to the evolving design 
details. This access requirement is accomplished by word of mouth and hard copy 
written documents. The access requirement is further accomplished through sharing 
access to a CAD/EDA system with the system operators. Sharing access to the Computer 
Aided Design/Computer Aided Engineering ("CAD/CAE") is required due to limited 
licenses and the specialized skills required for using a CAD/CAE system. 

Some CAD/EDA vendors provide viewers dedicated for their specific CAD/EDA 
data formats. All such viewers are restricted to a single format and do not allow a 
simultaneous access to different design abstractions (ex: schematic, layout or 
mechanical). Therefore, to compare a schematic and a layout of the same printed circuit 
board design, separate software applications must be opened for the schematic and 
layout, respectively, tying up excessive memory and requiring the user to be skilled in 
both applications. An ideal design data browsing system would provide simultaneous 
access to different design abstractions. 

Another problem arises when multiple applications are required to access multiple 
related designs. Applications often limit or define rules used for identifying device 
elements. Multiple related drawings in differing applications can make it difficult to 
identify like objects in the same device. Therefore, an ideal design data browsing system 
would provide a convenient method of identifying like objects of the same design on 
different abstractions (ex: signal names between schematic and layout) 
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Once captured, analyzed and resolved within the CAD/CAE system, design data 
is then communicated throughout the rest of the company by extracting particular 
sections of the design in the form of partial ASCII files, hard copy plots or reports. These 
communications are embellished with verbal and written messages. Some output formats 
can be viewed graphically in format specific viewers but only as flat drawings without 
database intelligence behind them. Ideally a design data browsing system would have 
viewers capable of viewing design drawings with database intelligence behind them. 

The original CAD/CAE data is thereafter moved off the CAD/EDA system to 
make room for the next design activity and is filed away in the design data storage vaults. 
Once there, the design work is no longer accessible unless it goes through a process of 
retrieval and reinstatement on the original CAD/CAE system. This process severely 
limits access to the totality of the design intent for most individuals in the company. Due 
to licensing expenses and related constraints, CAD/CAE personnel are normally the only 
group with full and unrestricted access to the data and then only until the design is filed 
away in data storage. Other individuals are forced to wait to use the CAD/CAE license, 
must be assisted by a knowledgeable operator while in front of the CAD/CAE systems, 
must wait for the plots and/or reports to be generated on the CAD/CAE department's 
schedule, or simply cannot access the data at all. Once the design data is stored away, the 
only information that remains readily accessible is partial, inconveniently packaged, and 
discarded among various parts of the organization. An ideal design data browsing system 
would enable complete and convenient access to design data, regardless of whether the 
data is part of an active project or has been archived. 

Summary of the Invention 

The present invention is the result of the realization that by providing a single 
software application capable of accessing and transmitting a complete electronic product 
design intent, including schematics, Pcb layout, mechanical, tabular abstractions and 
other intelligent drawings, without the need for the host CAD/CAE system, the 
application establishes a central cockpit for unrestricted browsing, querying and 
communicating of electronic product design information for the entire company. 

Therefore, it is an object of this invention to make all CAD/EDA data available 
without accessing the CAD/CAE system. 

It is a further object of this invention to provide a viewer capable of retrieving 
design data from data-vaulted drawings. 

It is a further object of this invention to automatically resolve multiple input data 
formats with the knowledge or interaction of the user. 

It is a further object of this invention to provide simultaneous access to different 
design abstractions from the same Data Model. It is a further object of this invention 
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to provide connectivity cross-reference between analogous design elements within and 
across different design abstractions of the same design. 

It is a further object of this invention to provide a single graphical viewer capable 
of viewing all associated design abstractions: logical, physical, mechanical and tabular. 

It is a further object of this invention to equip the application with the appropriate 
set of browsing, querying and communicating functions necessary to support particular 
tasks of the users., including network wide reference of related documents of any kind. 

It is a further object of this invention to establish an ease of use within the 
application that avoids the need for regular retraining for occasional users. 

It is a further object of this application to allow its use on and off the network. 

Advantages of the invention can be best understood in the context of electronic 
product hardware packaging and design phases. All electronic products can be divided 
into four levels of hardware packaging, as seen in Figure 2. 

IC Die (silicon by itself) 

IC Package (die in an enclosure) 

PCB(ICsonaboard) 

System (PCBs in an enclosure) 

Each packaging level (2.1-2.4) as well as transitions between the packaging levels (2.5- 
2.7) present a unique set of data sharing challenges. All of these levels are accessible 
through the invention as described below. 

During design of an integrated circuit ("IC") die 2.1, the logic expressed in HDL 
languages (behavioral abstraction) is automatically synthesized into physical blocks of 
gates and registers (physical abstraction). Once synthesized, the physical elements are 
then interconnected within the die using various block and gate level routing technologies 
together with foundry specific technology and manufacturing rules. Functionality of the 
resulting physical abstraction is then compared to the original HDL description through a 
combination of test benches and behavioral and functional simulations. Should an 
undesirable discrepancy be identified between the two, a detailed analysis of the physical 
layout is needed. 

The invention offers a unique and ideal platform for visualization of the physical 
design during this debugging phase and serves as an ideal source of design data for the 
analysis tools. It allows the design and the foundry engineers to browse all physical 
implementation aspects of the design and to correlate the logical abstraction to the 
physical details regardless of where the design originated. 

Die 2.1 design data can be communicated to the invention via the GDSII format, a 
standard in the die design industry. 
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Comments and review results can be communicated to the rest of the organization 
via custom display configurations, annotation in ASCII files, hard copy plots at any zoom 
factor, and spreadsheet reports. 

Packaging 2.5 of the IC die 2.1 within an IC enclosure 2.2 includes assignment of 
the external I/O pins on the die 2.1 to the corresponding internal I/O pins within the 
enclosure 2.2. Pins and signal assignments are manipulated in order to minimizes 
unnecessary electrical delays in the interconnect interface. This requires dynamic and 
simultaneous pin/signal mapping within the die 2.1 and the enclosure 2.2 while 
comparing and handling a variety of pin-out and net-list information. 

The invention offers a unique and ideal platform for dynamic exchange and 
visualization of the pin assignments between the die 2.1 and the enclosure 2.2 while 
eliminating the need for the exchange of data through plots, tables, spreadsheets or 
written notes. Because the invention is capable of displaying physical aspects of the die 
2.1 and the enclosure 2.2, it provides a common communication channel between the two 
design groups and serves as an ideal source of design data for the related electrical 
analysis tools. 

Die 2.1 design data can be communicated to the invention via the GDSII format, a 
standard in the die design industry. Enclosure 2.2 design data can be communicated to 
the invention via various enclosure/board level data formats. 

Comments and review results can be communicated to the rest of the organization 
via custom display configurations, annotation in ASCII files, hard copy plots at any zoom 
factor, and spreadsheet reports. 

IC enclosure 2.2 serves as a mechanical package for the die 2.1 plus an 
interconnect interface between the die 2.1 and the board 23. Designers and reviewers 
require access to the internal mechanical die mounting data as well as the interconnect 
mapping between the internal and external I/O pins. Pin and signal assignments are 
manipulated within the enclosure 2.2 in order to minimizes unnecessary electrical delays 
in the interconnect interface. This requires dynamic and simultaneous pin/signal 
mapping within the enclosure 2.2 while comparing and handling a variety of pin-out and 
net-list information. 

The invention offers a unique and ideal platform for dynamic exchange and 
visualization of the pin assignments within the enclosure 2.2 while eliminating the need 
for the exchange of data through plots, tables, spreadsheets or written notes. Because the 
invention is capable of displaying physical aspects of the die 2.1 and the enclosure 2.2, it 
provides a common communication channel between the two design groups and serves as 
an ideal source of design data for the related electrical analysis tools. 

Die 2.1 design data can be communicated to the invention via the GDSII format, a 
standard in the die design industry. Enclosure 2.2 design data can be communicated to 
the invention via various enclosure/board level data formats listed in the Appendix. 
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Comments and review results can be communicated to the rest of the organization 
via custom display configurations, annotation in ASCII files, hard copy plots at any zoom 
factor, and spreadsheet reports. 

IC enclosure 2.2 serves as an interconnect interface between the die 2.1 and the 
board 2.3. Designers and reviewers require access to the external mechanical IC 
enclosure 2.2 data as well as the interconnect mapping between the external enclosure 2.2 
I/O pins and the board 2.3 as the enclosure 2.2 is packaged 2.6 within the board 2.3. Pin 
and signal assignments are manipulated within the enclosure 2.2 and between the 
enclosure 2.2 and the board 2.3 in order to minimizes unnecessary electrical delays in the 
interconnect interface. This requires dynamic and simultaneous pin/signal mapping 
between the enclosure 2.2 and the board 2.3 while comparing and handling a variety of 
pin-out and net-list information. 

The invention offers a unique and ideal platform for dynamic exchange and 
visualization of the pin assignments between the enclosure 2.2 and the board 2.3 while 
eliminating the need for the exchange of data through plots, tables, spreadsheets or 
written notes. Because the invention is capable of displaying physical aspects of the 
enclosure 2.2 and the board 2.3, it provides a common communication channel between 
the two design groups and serves as an ideal source of design data for the related 
electrical analysis tools. 

Enclosure 2.2 and board 2.3 design data can be communicated to the invention via 
various enclosure/board level data formats listed in the Appendix. 

Comments and review results can be communicated to the rest of the organization 
via custom display configurations, annotation in ASCII files, hard copy plots at any zoom 
factor, and spreadsheet reports. 

Board design activity occurs in two major phases: logical (schematic) and 
physical (layout), 1.2. Although closely related, separate groups often perform the 
activities and the groups are often geographically dispersed. In addition the layout phase 
is often out-sourced to an outside vendor. 

Since the schematic and layout activities are closely related, both groups need a 
frequent and detailed exchange of design data and the related information. For example, 
the schematic designers need to indicate and review critical component placement and 
critical interconnect topologies whereas the layout designers need to annotate schematics 
with signal termination or part and net assignments. 

The invention offers a unique and ideal platform for dynamic exchange and 
visualization of the schematic and layout design data while eliminating the need for the 
exchange of data through plots, tables, spreadsheets or written notes. Because the 
invention is capable of representing all intelligent aspects of a design from all CAD/CAE 
systems, it provides a common communication channel between the all design groups 
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and serves as an ideal source of design data for the related design performance analysis 
tools. 

Board 2.3 design data can be communicated to the invention via various 
schematic/layout data formats listed in the Appendix. 

Comments and review results can be communicated to the rest of the organization 
via custom display configurations, annotation in ASCII files, hard copy plots at any zoom 
factor, and spreadsheet reports. 

The overall electronic system 2.4 must be packaged 2.7 into a physical unit that 
houses and interconnects all of the related electronic modules. While the detailed 
3-dimmentional design of the system 2.4 is performed on M-CAD systems, there is a 
point at which the mechanical and the electrical engineering must somehow relate one to 
the other. 

The invention offers a unique and ideal platform for dynamic exchange and 
visualization of the electronic layout data against its full 3D mechanical environment. 
Because the invention has an open application-programming interface ("API") available 
to other processes, it allows for dynamic exchange and correlation of design details with 
external 3D modeling tools. It provides a common communication channel between the 
mechanical and electrical design groups. 

Board 2.2 design data can be communicated to the invention via various layout 
data formats listed in the Appendix. 

Comments and review results can be communicated to the rest of the organization via 
custom display configurations, annotation in ASCII files, hardcopy plots at any zoom 
factor, and spreadsheet reports. 

Brief Description of the Drawings 

The novel features believed characteristic of the invention are set forth in the 
claims. The invention itself however, as well as other features and advantages thereof, 
will be best understood by reference to the description which follows, read in conjunction 
with the accompanying drawings, wherein: 

FIG. 1 shows an overview of a printed circuit board product life cycle. 
FIG. 2 shows an exploded view of the hardware packaging hierarchy of an 
electronic product. 

FIG. 3 shows a block diagram of one embodiment of the architecture of the 

inventive apparatus. 

FIG. 4 shows a flow diagram of one embodiment of the inventive method. 



{J:\wdox\docs\clients\l 082 1\5 1 085\M01 9164 1.1} 



Page 6 



Detailed Description of the Invention 



The invention is a software system that executes under any of the commercial 
operating systems ("OS") on the market: Windows, Unix, Linux and Apple and 
prospectively other operating systems developed in the future. It consists of the 
following core building blocks that are critical to the specific usefulness and 
characteristic of the invention: 

Multi platform execution (Fig 3A and 3B): 

o client/server implementation with like functionality across different OSs 

o same binary image for all Windows OSs (95, 98, NT, 2000 and Millennium) as well 

as their derivatives developed in the future 
o separate binary image for Unix versions, Linux versions and Apple OSs as well as 

other operating systems developed in the future 

Client/server means that the invention modules interact among two or more 
networked computers as documented in Fig 3A and 3B (3.1 1, 3.12, 3.14, 3.17 and 3.20). 
This feature includes the case where all services that can be distributed over several 
servers in fact reside on a single computer without the need for the network. 

-Application Client 3.11: 

Application Client is the node from which the invention is initiated and on which it 
actually executes. This is the node from which the user interacts with the invention. 

Application Server 3.12: 

Application Server is the node where the invention modules are installed on a disk 
3.13. An execution request from the Client 3.11 forces automatic transfer of the 
appropriate modules from the Server's disk to the Client's memory where they reside for 
the duration of the invention execution. Application Client and Application Server may 
be the same computer node. 

Proprietary and memory resident run-time database 3.4: 

o CAD/EDA objects required to represent an intelligent PCB layout design 

o CAD/EDA objects required to represent an intelligent schematic design 

o CAD/EDA objects required to represent a 2.5D mechanical design 

o CAD/EDA objects required to represent a functional block diagram 

The run-time database 3 .4 constitutes the heart of the invention. It is a fundamental 
building block that always must be present in all configurations of the invention. This 
database keeps all of the CAD/EDA data constructs, properties and functional 
characteristics. In a Client/Server environment this database always resides on the 
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Client node but is accessible from other nodes on the network. Location of the run-time 
database on the Client is critical for invention's performance on large designs. 

-License Server 3.14 

License Server is the node that holds the licensing mechanism for the invention in a 
form of a disk based license file 3.15 and a memory resident license manager 3.16. 
Application Client and License Server may be the same computer node. 

-Licensing mechanism 3.6 and 3.14-16: 

o Client/Server licensing model 

o Floating and Node Locked licensing modes 

o Time limited conversion of licenses from Floating to Node Locked 

o Date based expiration 

o Control for simultaneous number of users 

An execution request from the Client 3.11 forces automatic license verification 3.6 by 
accessing services of the License Server. A unique aspect of this invention's licensing is 
the ability to take a Floating license and convert it to a time-limited Node Locked license. 
This enables a networked user to continue working without being on a net. This is 
accomplished via interaction of the invention with the services of a Web Server dedicated 
to the invention 3.20. 

Graphical User Interface 3.7: 

o client implementation with like functionality across different OSs 

o Point-and-click implementation of drop down menus, tool bars with icons, and dialog 
boxes 

o loading of design data (CAD/CAE designs and annotations) 

o exporting and importing of design data annotations (markups, bookmarks and 

overlays) 

o printing and plotting 

o display manipulation (visibility, zoom, color, highlight, units, etc.) 

o navigation of the design structures (hierarchy, connectivity) 

o search (finding objects by their characteristics) 

o measure (distances within or between graphical representations of physical objects) 

o query of design objects (examining non-graphic characteristics of objects) 

o interactive entry of annotations, including bookmarks 

The run-time UI 3.7 constitutes the primary means of interactive access to the 
invention. The run-time UI 3.7 graphically presents the data on the local computer and 
provides access to all interactive invention commands. It is a fundamental building block 
but it may not be present in all configurations of the invention. If not present, then the 
invention is a run-time database accessible through API. In client/server environment 
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this run-time UI 3.7 is a client that must reside on the networked node from which the 
invention is launched and used. 

Integration with the basic Internet environment 3 .25 : 

o support of URL links for loading design data directly from the Internet 3.1 1 and 

from packet data module ("PDM") processes 3.19. 
o support of URL links for dynamic reference between objects in the invention and 

data on the Internet 3.8. 
o support of MAPI links for direct exchange of design data between the invention and 

the local e-mail application 3.10. 

Integration with Internet means the invention is able to communicate through basic 
high-level Internet mechanisms such as the IMAP application protocols and the URL data 
links. IMAP enables exchange of data with the local e-mail package 3. 10. URL allows 
reaching data files (read/write) and data objects anywhere on the Internet. 

Report Writer (Fig 3, item 3.8) 

While the Tool is active with a loaded Data Model 3.4 the invention is capable of 
generating spreadsheet reports directly into spreadsheet format files (such as *.csv) in the 
absence of the specific spreadsheet software. These reports contain detailed information 
about specific objects such as but not limited to: BOM, net topology, test points, etc. 
Annotation Writer 3 .23 : 

o ASCII scripting language that can be created and manipulated with the basic text 
editors 

o Local and global script path search algorithm that allows for default script loading 
o script API within the invention 3.5 

o definition of the initial state of the invention on start (command defaults, visibility 

defaults, data load defaults) 
o definition of the user-defined run-time states of the invention during execution, 

referred to as bookmarks (command defaults, visibility defaults, data load 

defaults) 

Scripting language allows the user to control local configuration and behavior of the 
run-time UI 3.7. It is a "hard copy" log of Query API 3.5 calls captured into the run-time 
UI 3.7 or on a disk. Individual script sections are called bookmarks. Bookmarks can be 
applied during software launch (a start-up control) or during execution, bookmark. 
During the execution, scripts can be loaded or generated. Generating a script while using 
the invention helps to capture a particular state of the configuration and then to 
communicate it to other users or to recall it later on during the process. 

- Format Readers 3.1: 
o Automatic matching of data with a reading module 3 . 1 -3 .2 
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o Open API for creating custom format readers 3.3 

Reading modules import data from a specific external file into the Client's run-time 
memory resident Data Model 3.4. They are implemented as modules that are separate 
from the memory resident Data Model 3.4. The reading modules 3.1-3.2 are used to load 
external data into the invention's run-time Data Model 3.4. These modules communicate 
with the invention through open API 3.3 that is independent of the OS platform. Data is 
loaded either as the design data or as additional information (notes/redlines or overlays) 

-Format Verifier 3.2 

As input design data format is presented to the invention the verifier 3.2 automatically 
matches an appropriate format reader 3.1 with the file's format. This is done without any 
interaction or specific directive from the user. 

-Import API 3.3 

All data is put into the run-time memory resident Data Model 3.4 via an API 3.3. This 
allows continuous development and refinement of the Data Model and the format readers 
3.1 with minimum impact on each other. 

-Data Server 3.17 

All design related data used by the invention resides on a PDM System 3.1 8 and is 
reachable via Internet URL protocol. Application Client and Data Server 3.17 may be the 
same computer node. 

-PDM Process 3.18 

Design Data from Data Server may also be presented to the invention by a locally 
deployed PDM system. This is accomplished either by PDM loading data directly into 
the Data Model 3.4 via the Import API 3.3 or by opening the appropriate design file via a 
register application and it's library of format readers 3.1. 

-Query API 3.5 

While the inventive software is active with a loaded Data Model 3.4 the Data Model 3.4 
can be accessed and controlled via a Query API 3.5. This API 3.5 allows querying Data 
Model 3.4 for existence of specific objects or for object properties by any outside process 
(ex: what are all the nets, or what are the pins on a particular net, etc.). The API 3.5 also 
allows controlling the state of the software (ex: zoom to a location, or highlight an object, 
etc.). The outside process may be another instantiation, which enables activities such as 
cross-highlighting 4.19 and design compare. 
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-Other Processes 3,9 

Other Processes are any applications capable of using the Query API 3.5for dynamic 
interaction and exchange of information with the software. 

-e-Mail Process 3.10 

The e-mail process includes any active e-mail package capable of MAPI protocol support 
that resides on the Application Client. The invention uses MAPI protocol to 
communicate Annotation scripts 3.23 in the foim of an attached file. 

- Web Server 3.20 

o a protected WEB portal designed for interactive sharing of design data 

o a chat room-like environment with graphical and textual data exchange 

o interactive pushing of the invention's state (bookmarks) from the invention to the 

WEB portal 

o interactive pulling of the invention's state (bookmarks) from the WEB portal to 
the invention 

The WEB portal is a software service on the Internet with a tight integration of data 
exchange between the invention and the WEB portal. Using the invention 's Internet 
communication protocol users can link into a community of interactive participants for 
the purpose of reviewing, commenting on and sharing information regarding designs 
resident in the invention's run time database. By pushing/pulling graphical the 
invention's graphical data to/from the portal, all participants can be actively engaged in a 
design discussion even if they are geographically dispersed. This server is typically 
outside the company's firewall 3.24. 

-WEB Server files 3.21 

A collection of design related data accumulated by the users via the software 
communication capabilities 3.8 and 3.10. 

-WEB Server process 3.22 

WEB portal process dedicated to managing user communication regarding design data. 

-Firewall 3.25 

Network separation between Inter and Intranet data access. Firewall3.25 prevents 
external users (customers on the WEB portal and recipients of Annotation files or 
Bookmark scripts) from having an unauthorized access to design data residing on an 
internal company's Data Server 3.17. 
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The invention further includes an inventive process. The process, as shown in Figure 
4, includes the following steps: 



4. 1 Start the system on which the inventive software (the "Tool") will be run. 

42 Invoke the Tool. 

The Tool can be invoked in a variety of ways: 

- Click on the Tool icon 

- Click on a data file registered against the Tool 

- Drag/Drop of a file icon over the Tool icon 

- System directive from an independent process such as PDM. 

The Tool itself may reside on the Client or on a Server. When the Tool resides on a 
Client, then it is invoked as any other software that resides on this Client. When it 
resides on a Server then the Tool is invoked by loading itself into the local memory 
followed by registering on the Client all reading and writing modules found on the 
Server. 

43 Search for a license 

After initiating on the Client but before allowing selection of a data file the Tool 
goes through a license verification process 3.6. The license can be retrieved from a 
Client or from a Server 3.14-3.16, depending on the configuration. 

In case the license is not found automatically, the Tool initiates an interactive 
sequence by requesting the user to explicitly identify location of a license anywhere 
on the network. 

A license may also be obtained for operating the Tool off of the Internet. A license 
for operating using the Internet is called a Floating license. Once a Floating license 
is granted, the user has an option to convert it into what is termed a temporary Node 
Locked license. This license allows the user to continue the work off the Internet. 
This process is referred to as Consignment Licensing and it requires active access to 
the appropriate Web services 3.22. This action can be performed at any time after 
successful initiation of the Tool. 

4.4-5 License Found? decision 

The Tool will not initiate unless a valid license is located. However, the user is 
presented with an opportunity to request a license from Web services 3.22 before the 
Tool exits. 

4.6 Select a Design file 

A design file may be selected in a variety of ways: 
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- Click on a data file registered against the software before the Tool initiates. 

- Drag/Drop of a file icon over the Tool icon before the Tool initiates. 

- System directive from an independent process such as PDM 

- Open Design command from a File menu after the Tool initiates. 

- Defined as a URL link in a Bookmark script. 

Once a file is identified the Tool initiates search for an appropriate format reader. 

4.7 Search for a Parser (Fig 4, item 4.7) 

At first the Tool attempts to match the file extension to a format reader 3.1 
associated with it If the extension is not recognized, then the file is presented to the 
first available reader 3.1. 

The reader 3.1 opens the file and the format verifier 3.2 verifies the beginning of the 
file does correspond to the proper format. If it corresponds, the reader 3.1 informs 
the Data Model 3.4 of a success and proceeds to read the rest of the file. If it does 
not correspond, then the reader 3.1 informs the Data Model 3.4 of a failure and exits. 

If the Data Model 3.4 is informed of a failure then it presents the file to the next 
available reader 3.1 until the format is recognized or until there are no more readers 
3.1 available. If the Data Model 3.4 is informed of a success then it waits until the 
Reader 3.1 is finished loading the data. 

This step of the process relieves the user from having to know anything about the 
source or the format of the file. 

4.8 Parser found? decision 

If the last Reader available fails to recognize the data format then the Tool proceeds 
to step 4.22. 

4.9 Load the Design file 

The import API 3.3 converts Data Model of the file format to the Data Model 3.4 of 
the Tool and creates a run-time database. 

4.10 Load the Default Annotation files 

After finishing loading of a design file, the Tool initiates loading of the default 
Annotation files through the format readers 3.1. These files contain scripts that 
define the initial state of the Tool. They also contain scripts that define Bookmarks, 
which are various other states of the Tool that can be invoked by name anytime after 
the data loading is finished. 
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The default Annotation files are located by their names and paths according to a 
fixed search scenario file pathname. This allows automatic loading of specific Tool 
configurations with respect to the design. 

4. 1 0 Load the Other Annotation files 

The user, through the appropriate Annotation file load procedureand using format 
readers 3.1, may also load annotation files at any time after design load is 
completed. User loaded Annotation files may also contain Redline in addition to the 
Bookmark scripts. Redlines represent design markups created by other users. 

This step is repeated at various times in order to facilitate asynchronous 
collaboration with other Tool users. Each user can read data whenever appropriate 
and without requiring the other user to be on-line. 

4.12-17Load the Overlay files 

After finishing loading of a design file, the user may load any number of Overlays 
through the appropriate Annotation file load procedure and using format readers 3.1 
Overlays allow visual matching of various physical definitions of a design (ex: 
component placement contained in a design file vs. pad definitions contained in an 
associated Gerber film.) 

Overlay data is typically expressed in many different formats. A similar 
loading/parsing technique is used as in the case of design data thereby relieving the 
user from having to know what format is used in the first place. The only difference 
from design load is that the Tool issues an appropriate message without terminating 
the run in case a parser is not found. 

4.18 Browse, Query 

The user starts Browsing 4.18 and Querying 4.19 design data according to her needs 
at any time after loading design data. This is done via the various functions and 
options of the run-time UI 3.7 and continues at the user's discretion. 

4. 1 8 Query - Cross Highlight 

The user invokes Cross-Highlighting operations between any two sessions of the Tool 
at any time after loading design data. This can also be accomplished between the 
Tool and some other process. Cross Highlighting allows one Tool to communicate 
an object of interest (Pin, a Component and/or Net) to the other Tool for visual 
highlighting. 

In case of a Net, the Tool employs an algorithm where the corresponding Nets are 
identified by their connectivity (pins) instead of their specific Net names. This is 
critical since many schematic and printed circuit board ("PCB") systems create data 
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with altered signal names between the two abstractions. It also allows for efficient 
Cross Highlighting of bus structures. 

4.20 Collaborate - Markups 

The user invokes the process of creating markups at any time after loading design 
data. This is accomplished with drafting and text-editing functions, which place data 
on dedicated Overlay within the memory resident Efata Model 3.4. Markups are used 
to clearly indicate areas of particular interest within the graphical context of a design. 

Once entered, markup text can be automatically located via the Search mechanism. 
Markup text is listed in Search in a way that allows the user to pan/zoom to its exact 
location by clicking on the appropriate entry in the listing. 

Collaborate - Bookmarks 

The user invokes the process of defining Bookmarks at any time after loading design 
data. Bookmarks are named scripts which capture a specific state of the Tool 
including: 

- States of all commands 

- Snap shot of zoom, pan, visibility and colors 

- Snap shot of all highlighted objects (Pins, Components and Nets) 

- Snap shot of all existing markups 

Each Bookmark has a unique user defined name, which allows recalling them at 
any time with a click of a mouse. 

Collaborate - Communicate 

The user invokes the process of communicating Bookmarks at Markups at any time 
after defining them. Such user-defined data can be sent instantly via an automatic 
attachment to e-mail 3.10 or by storing an external Annotations file that will be 
shared with others at a later time. Annotation files can also be used to recall previous 
states of the Tool (analogous to backup/restore or undo operations). 

These Annotation files are preferably written in an XML syntax enabling other 
processes to use them as well. They also contain URL links to the design data itself 
thereby avoiding multiple replication of the original design file. These URL links 
also provide a protection against unwarranted disclosure of the design data, which 
always resides in its original location (ex: behind the company's intranet fire wall 
3.24). 

This step is repeated at various times in order to facilitate asynchronous 
collaboration with other Tool users. Each user can read data whenever appropriate 
and without requiring the other user to be on-line. 
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Therefore, the foregoing is considered as illustrative only of the principles of the 
invention. Further, since numerous modifications and changes will readily occur to those 
skilled in the art, it is not desired to limit the invention to the exact construction and 
operation shown and described, and accordingly, all suitable modifications and 
equivalents may be resorted to, falling within the scope of the invention. 

Accordingly, what is claimed is: 
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